Ссылки по теме * [Arch packaging standards (Русский)](/index.php/Arch_packaging_standards_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Arch packaging standards (Русский)") * [Arch Build System (Русский)](/index.php/Arch_Build_System_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Arch Build System (Русский)") * [Создание пакетов](/index.php/%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2 "Создание пакетов") * [Категория:Разработка пакетов](/index.php/Category:Package_development_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Category:Package development (Русский)") * [pacman/Советы и приёмы](/index.php/Pacman/%D0%A1%D0%BE%D0%B2%D0%B5%D1%82%D1%8B_%D0%B8_%D0%BF%D1%80%D0%B8%D1%91%D0%BC%D1%8B "Pacman/Советы и приёмы") * [Arch User Repository (Русский)](/index.php/Arch_User_Repository_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Arch User Repository (Русский)") * [makepkg (Русский)](/index.php/Makepkg_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Makepkg (Русский)") * [pacman (Русский)](/index.php/Pacman_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Pacman (Русский)") В этой статье приведен список переменных, которые мейнтейнеры описывают в файлах PKGBUILD. Для получения информации о функциях, используемых в этих файлах, а также о создании пакетов в целом, смотрите статью [Создание пакетов](/index.php/%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2 "Создание пакетов"). PKGBUILD — это shell-скрипт, содержащий информацию, необходимую для сборки пакетов [Arch Linux](/index.php/Arch_Linux_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Arch Linux (Русский)"). Пакеты в Arch Linux собираются при помощи утилиты [makepkg](/index.php/Makepkg_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Makepkg (Русский)") . При запуске она ищет в текущем каталоге файл `PKGBUILD` и следует инструкциям из него, чтобы либо скомпилировать код, либо получить файлы для сборки пакета (`*имя_пакета*.pkg.tar.xz`). Готовый пакет содержит двоичные файлы и инструкции по установке, благодаря чему может быть легко установлен при помощи [pacman](/index.php/Pacman_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Pacman (Русский)"). Переменные `pkgname`, `pkgver`, `pkgrel` и `arch` являются обязательными. `license` не является строго необходимой для сборки пакета, но рекомендуется для любых файлов PKGBUILD, которые вы желаете распространять. *makepkg* будет выводить предупреждение, если эта переменная не указана. Общепринятой практикой является определение переменных в PKGBUILD в том порядке, в котором они приведены здесь. Однако, это не обязательно — главное, чтобы использовался корректный синтаксис [Bash](/index.php/Bash_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Bash (Русский)"). ## Contents * [1 Имя пакета](#.D0.98.D0.BC.D1.8F_.D0.BF.D0.B0.D0.BA.D0.B5.D1.82.D0.B0) * [1.1 pkgbase](#pkgbase) * [1.2 pkgname](#pkgname) * [2 Версия](#.D0.92.D0.B5.D1.80.D1.81.D0.B8.D1.8F) * [2.1 pkgver](#pkgver) * [2.2 pkgrel](#pkgrel) * [2.3 epoch](#epoch) * [3 Общие](#.D0.9E.D0.B1.D1.89.D0.B8.D0.B5) * [3.1 pkgdesc](#pkgdesc) * [3.2 arch](#arch) * [3.3 url](#url) * [3.4 license](#license) * [3.5 groups](#groups) * [4 Зависимости](#.D0.97.D0.B0.D0.B2.D0.B8.D1.81.D0.B8.D0.BC.D0.BE.D1.81.D1.82.D0.B8) * [4.1 depends](#depends) * [4.2 optdepends](#optdepends) * [4.3 makedepends](#makedepends) * [4.4 checkdepends](#checkdepends) * [5 Отношения](#.D0.9E.D1.82.D0.BD.D0.BE.D1.88.D0.B5.D0.BD.D0.B8.D1.8F) * [5.1 provides](#provides) * [5.2 conflicts](#conflicts) * [5.3 replaces](#replaces) * [6 Остальные](#.D0.9E.D1.81.D1.82.D0.B0.D0.BB.D1.8C.D0.BD.D1.8B.D0.B5) * [6.1 backup](#backup) * [6.2 options](#options) * [6.3 install](#install) * [6.4 changelog](#changelog) * [7 Исходные коды](#.D0.98.D1.81.D1.85.D0.BE.D0.B4.D0.BD.D1.8B.D0.B5_.D0.BA.D0.BE.D0.B4.D1.8B) * [7.1 source](#source) * [7.2 noextract](#noextract) * [8 Целостность](#.D0.A6.D0.B5.D0.BB.D0.BE.D1.81.D1.82.D0.BD.D0.BE.D1.81.D1.82.D1.8C) * [8.1 md5sums](#md5sums) * [8.2 sha1sums](#sha1sums) * [8.3 sha256sums, sha384sums, sha512sums](#sha256sums.2C_sha384sums.2C_sha512sums) * [9 Смотрите также](#.D0.A1.D0.BC.D0.BE.D1.82.D1.80.D0.B8.D1.82.D0.B5_.D1.82.D0.B0.D0.BA.D0.B6.D0.B5) ## Имя пакета ### pkgbase Необязательная глобальная переменная, доступная при сборке разделенного пакета. Используется для обращения к группе пакетов в выводе *makepkg*, а также при именовании архивов с одними лишь исходными файлами. Если она не указана, будет использоваться первый элемент массива `pkgname`. В этой переменной нельзя использовать дефис в качестве первого символа. Все опции и указания для раздельных пакетов ставятся по умолчанию глобальным переменным, данным в PKGBUILD. Тем не менее, они все, за исключением `makedepends`, переменных [исходного кода](#.D0.98.D1.81.D1.85.D0.BE.D0.B4.D0.BD.D1.8B.D0.B5_.D0.BA.D0.BE.D0.B4.D1.8B) и [проверки целостности](#.D0.A6.D0.B5.D0.BB.D0.BE.D1.81.D1.82.D0.BD.D0.BE.D1.81.D1.82.D1.8C), могут быть переопределены в функции `package()` каждого отдельного пакета. ### pkgname Имя пакета. Оно может состоять из латинских букв и цифр, а также следующих символов: `@`, `.`, `_`, `+`, `-` (собака, точка, знак подчеркивания, плюс, дефис). Все буквы должны быть строчными, а имена не должны начинаться с дефиса. Для единообразия, `pkgname` должен совпадать с именем архива с исходным кодом программы, которую вы упаковываете. Например, если исходный код программы упакован в архив с именем `foobar-2.5.tar.gz`, переменная `pkgname` должна иметь значение `foobar`. Имя текущего каталога сборки, в котором находится файл PKGBUILD, также должно совпадать с `pkgname`. Имена для разделенных пакетов должны быть определены при помощи массива, например, так: `pkgname=('foo' 'bar')`. ## Версия ### pkgver Версия пакета. Это значение должно совпадать с номером версии пакета, выпущенного его автором. Оно может содержать буквы, цифры, точки и знаки подчеркивания, но **не** дефисы (`-`). Если автор пакета использует дефис в своей схеме нумерации пакетов, замените его знаком подчеркивания (`_`). Если переменная `pkgver` используется позднее в PKGBUILD, знак подчеркивания можно легко заменить на дефис, например, так: `source=("$pkgname-${pkgver//_/-}.tar.gz")`. **Примечание:** Если в выпусках программы используется обозначение версий по датам, например, `05102014`, обязательно используйте обратный порядок следования, т.е. `20141005` (формат [ISO 8601](https://en.wikipedia.org/wiki/ru:ISO_8601 "wikipedia:ru:ISO 8601")). В противном случае новые версии пакета не будут считаться более свежими **Совет:** [makepkg](/index.php/Makepkg_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Makepkg (Русский)") способен автоматически [обновлять](http://allanmcrae.com/2013/04/pacman-4-1-released/) эту переменную, если в PKGBUILD определить функцию `pkgver()`. Для получения дополнительной информации смотрите раздел [VCS package guidelines#The pkgver() function](/index.php/VCS_package_guidelines#The_pkgver.28.29_function "VCS package guidelines") ### pkgrel Номер релиза. Это значение позволяет пользователям различать сборки одной и той же версии пакета. Когда в PKGBUILD вносятся исправления и добавляются новые возможности, влияющие на итоговый пакет, `pkgrel` должен быть увеличен на 1\. Когда же выходит новая версия программного обеспечения, это значение должно быть сброшено на 1. ### epoch **Важно:** Переменная `epoch` должна использоваться лишь в тех случаях, когда вы абсолютно уверены в ее необходимости Используется для того, чтобы версия пакета принудительно воспринималась как наиболее свежая по сравнению со всеми другими версиями, у которых указано меньшее значение `epoch` (невзирая на их номера). Эта переменная должна иметь целое положительное значение; если она не указана, считается, что ее значение равно 0\. Она полезна, когда схема нумерации версий пакета меняется (или является буквенно-цифровой) и необходимо обойти логику нормального сравнения версий. Например: ``` pkgver=5.13 pkgrel=2 epoch=1 ``` `1:5.13-2` Для получения дополнительной информации о сравнении версий смотрите [страницу справочного руководства](/index.php/Man_page_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Man page (Русский)") [pacman(8)](https://www.archlinux.org/pacman/pacman.8.html). ## Общие ### pkgdesc Описание пакета. Рекомендуется использовать не более 80 символов и не использовать имя пакета, за исключением случаев, когда имя приложения отличается от имени пакета. Например, вместо `pkgdesc="Nedit — текстовый редактор для X11"` следует написать просто: `pkgdesc="Текстовый редактор для X11"`. Также помните, что очень важно активно использовать ключевые слова, чтобы увеличить вероятность нахождения пакета при помощи поисковых запросов. ### arch Массив с именами архитектур, на которых можно осуществить сборку с данным файлом PKGBUILD и, в конечном итоге, работать с пакетом. В Arch официально поддерживаются только `i686` и `x86_64`, но такие проекты, как, например, [Arch Linux ARM](http://archlinuxarm.org/), предоставляют поддержку других архитектур, таких как `armv5`, `armv6`, `armv7` и `armv8`. Если после компиляции пакета его работа не зависит от архитектуры (скрипты оболочки, шрифты, темы оформления, различные расширения и т.п.), используйте значение `arch=('any')`. Обратите внимание, что это относится к пакетам, которые можно собрать единожды и в дальнейшем использовать на любой архитектуре. В архитектуре таких пакетов будет указано `-any`, а не `-i686`, `-x86_64` или что-то подобное. Если же пакет можно скомпилировать на любой архитектуре, но после компиляции он становится архитектурозависимым, укажите все архитектуры, официально поддерживаемые в Arch, т.е. `arch=('i686' 'x86_64')`. Вы можете узнать архитектуру машины, на которой производится сборка, с помощью переменной `$CARCH`. ### url Адрес официального сайта упаковываемого программного обеспечения. ### license Лицензия, под которой распространяется программное обеспечение. В пакете [licenses](https://www.archlinux.org/packages/?name=licenses) из [официальных репозиториев](/index.php/Official_repositories_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Official repositories (Русский)") содержится множество наиболее известных лицензий, которые устанавливаются в каталог `/usr/share/licenses/common`. Если пакет распространяется под одной из этих лицензий, переменной должно быть присвоено имя соответствующего каталога, например, `license=('GPL')`. Если требуемая лицензия не включена в официальный пакет [licenses](https://www.archlinux.org/packages/?name=licenses), вы должны сделать несколько вещей: 1. Добавьте значение `custom` в массив `license`. Также вы можете заменить `custom` на `custom:*имя лицензии*`. Как только лицензия будет использована в двух и более пакетах из официальных репозиториев (включая `[community]`), она будет включена в пакет [licenses](https://www.archlinux.org/packages/?name=licenses) 2. Устанавливайте лицензию в каталог `/usr/share/licenses/*имя_пакета*/`, например, `/usr/share/licenses/foobar/LICENSE` 3. Если лицензию можно найти лишь на веб-сайте, все равно необходимо включить ее в пакет * Лицензии [BSD](https://en.wikipedia.org/wiki/ru:%D0%9B%D0%B8%D1%86%D0%B5%D0%BD%D0%B7%D0%B8%D1%8F_BSD "wikipedia:ru:Лицензия BSD"), [MIT](https://en.wikipedia.org/wiki/ru:%D0%9B%D0%B8%D1%86%D0%B5%D0%BD%D0%B7%D0%B8%D1%8F_MIT "wikipedia:ru:Лицензия MIT"), [zlib/png](https://en.wikipedia.org/wiki/ru:%D0%9B%D0%B8%D1%86%D0%B5%D0%BD%D0%B7%D0%B8%D1%8F_zlib "wikipedia:ru:Лицензия zlib") и [Python](https://en.wikipedia.org/wiki/Python_License "wikipedia:Python License") являются отдельными случаями и не могут быть включены в пакет [licenses](https://www.archlinux.org/packages/?name=licenses). Ради массива `license` они рассматриваются как текущие лицензии (`license=('BSD')`, `license=('MIT')`, `license=('ZLIB')` и `license=('Python')`), но технически каждая из них является пользовательской, потому что содержит свой собственный копирайт. Любые пакеты, распространяющиеся под одной из этих четырех лицензий, должны иметь свою собственную уникальную лицензию, расположенную в `/usr/share/licenses/*pkgname*`. Некоторые пакеты могут распространяться не только под одной лицензией. В этих случаях вы можете создавать несколько записей в массиве `license`, например, `license=('GPL' 'custom:*имя лицензии* ')` * (L)GPL имеет много версий и редакций этих версий. Для программного обеспечения, распространяемого под (L)GPL, общепринято указывать: * (L)GPL — (L)GPLv2 или любая более поздняя версия * (L)GPL2 — только (L)GPL2 * (L)GPL3 — (L)GPL3 или любая более поздняя версия * Если после всего этого вы не можете определиться с лицензией, [PKGBUILD.proto](https://projects.archlinux.org/pacman.git/tree/proto/PKGBUILD.proto) предлагает использовать значение `unknown`. Однако, необходимо связаться с разработчиком для выяснения условий, под которыми программное обеспечение может (и не может) распространяться **Совет:** Некоторые авторы программного обеспечения не предоставляют отдельного файла лицензии, а описывают правила распространения в разделе файла `ReadMe.txt`. Эта информация может быть записана в отдельный файл в процессе выполнения функции `build()` при помощи команды наподобие `sed -n '/**This software**/,/ **thereof.**/p' ReadMe.txt > LICENSE` ### groups [Группа](/index.php/Pacman_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)#.D0.A3.D1.81.D1.82.D0.B0.D0.BD.D0.BE.D0.B2.D0.BA.D0.B0_.D0.B3.D1.80.D1.83.D0.BF.D0.BF.D1.8B_.D0.BF.D0.B0.D0.BA.D0.B5.D1.82.D0.BE.D0.B2 "Pacman (Русский)"), к которой принадлежит пакет. Например, когда вы пытаетесь установить пакет [kdebase](https://www.archlinux.org/groups/x86_64/kdebase/), устанавливаются все пакеты, входящие в эту группу. ## Зависимости **Примечание:** Вы можете использовать специфичные для разных архитектур массивы путем добавления символа подчеркивания и имени архитектуры, например, `depends_x86_64=()`, `optdepends_x86_64=()` ### depends Массив имен пакетов, которые должны быть установлены для запуска программы из данного пакета. Диапазоны совместимых версий можно указать при помощи операторов сравнения (пример: `depends=('foobar>=1.8.0')`). Если необходимо указать несколько ограничений, зависимость можно повторить для каждого из них [[1]](https://mailman.archlinux.org/pipermail/arch-general/2012-July/029022.html) (пример: `depends=('foobar>=1.8.0' 'foobar<2.0.0')`). Нет необходимости указывать зависимости, предоставляемые пакетами, от которых зависит ваш пакет. Например, если пакет *foo* зависит от *bar* и *baz*, и, в свою очередь, пакет *bar* зависит от *baz*, то не следует включать пакет *baz* в массив `depends` пакета *foo*. ### optdepends Массив имен пакетов, которые не требуются для работы программы, но предлагают дополнительные функции. Это может означать, что не все исполняемые файлы, предоставляемые пакетом, будут работать без соответствующих дополнительных зависимостей [[2]](https://lists.archlinux.org/pipermail/arch-general/2014-December/038124.html). Если программное обеспечение может работать с разными альтернативными зависимостями, их можно указать здесь, а не в массиве `depends`. Также должно быть указано короткое описание того, что дает каждый пакет: ``` optdepends=( 'cups: printing support' 'sane: scanners support' 'libgphoto2: digital cameras support' 'alsa-lib: sound support' 'giflib: GIF images support' 'libjpeg: JPEG images support' 'libpng: PNG images support' ) ``` ### makedepends Массив имен пакетов, которые должны быть установлены **лишь** для сборки пакета, но не нужны для использования программы после установки. Вы можете указать минимальную версию зависимости для пакетов в том же формате, что и в массиве `depends`. **Совет:** Чтобы узнать, является ли какой-либо пакет частью группы [base-devel](https://www.archlinux.org/groups/x86_64/base-devel/) или будет ли он вытянут как зависимость других пакетов группы, вы можете использовать следующую команду: ``` $ pacman -Si $(pactree -rl *пакет*) 2>/dev/null | grep -q "^Groups *:.*base-devel" ``` **Примечание:** Предполагается, что группа [base-devel](https://www.archlinux.org/groups/x86_64/base-devel/) уже установлена для сборки при помощи *makepkg*. Пакеты этой группы **не должны** включаться в массив `makedepends` ### checkdepends Массив имен пакетов, от которых зависит запуск собственных тестов пакета, но ненужных для его последующей работы. Пакеты в этом списке должны иметь такой же формат, как и в `depends`. Эти зависимости должны быть прописаны, только если *makepkg* должен выполнять функцию [check()](/index.php/Creating_packages#check.28.29 "Creating packages"). **Примечание:** Предполагается, что группа [base-devel](https://www.archlinux.org/groups/x86_64/base-devel/) уже установлена для сборки при помощи *makepkg*. Пакеты этой группы **не должны** включаться в массив `checkdepends` ## Отношения **Примечание:** Вы можете использовать специфичные для разных архитектур массивы путем добавления символа подчеркивания и имени архитектуры, например, `provides_x86_64=()`, `conflicts_x86_64=()` ### provides Массив имен пакетов, которым этот пакет придает дополнительный функционал (или виртуальный пакет вроде `cron` или `sh`). Пакеты, предоставляющие одни и те же функции, могут быть установлены в одно и то же время только если ни в одном из них второй не указан в массиве `conflicts`. **Важно:** Если вы используете эту переменную, вы должны добавить версию (`pkgver` и, возможно, номер сборки `pkgrel`), которую этот пакет предоставит, если это затрагивает зависимости. Например, если вы создали модифицированный пакет *qt* версии 3.3.8, названный *qt-foobar*, массив `provides` должен выглядеть так: `provides=('qt=3.3.8')`. Если написать `provides=('qt')`, могут быть нарушены те зависимости, которые требуют конкретную версию *qt*. Не добавляйте `pkgname` в ваш массив `provides`: это будет сделано автоматически ### conflicts Массив имен пакетов, которые могут вызвать проблемы при наличии в системе. Все эти пакеты, а также пакеты, предоставляющие соответствующие программы, будут удалены. Вы также можете указать версии конфликтующих пакетов в том же формате, что и в массиве `depends`. ### replaces Массив имен устаревших пакетов, которые замещаются этим пакетом. Например, в пакете [wireshark-gtk](https://www.archlinux.org/packages/?name=wireshark-gtk) используется `replaces=('wireshark')`. После синхронизации *pacman* немедленно заменит установленный пакет на другой, из репозиториев, с соответствующей записью в `replaces`. Если вы предоставляете альтернативную версию уже существующего пакета или загружаете его в [AUR](/index.php/Arch_User_Repository_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Arch User Repository (Русский)"), используйте массивы `conflicts` и `provides`, которые необходимы только при установке конфликтующего пакета. ## Остальные ### backup Массив имен файлов, которые могут содержать изменения, сделанные пользователем, и должны быть сохранены в процессе обновления или удаления пакета. В первую очередь эта переменная предназначена для конфигурационных файлов в `/etc`. Пути к файлам в этом массиве должны быть **относительными**, без предваряющего их слеша (`/`) (например, `etc/pacman.conf` вместо `/etc/pacman.conf`). При обновлении новая версия файла может быть сохранена как `файл.pacnew` во избежание перезаписи старой версии файла, который уже существует и был ранее изменен пользователем. Аналогичным образом при удалении пакета файлы, измененные пользователем, будут сохранены как `файл.pacsave` до тех пор, пока пакет не будет удален командой `pacman -Rn`. Смотрите также статью [Файлы Pacnew и Pacsave](/index.php/%D0%A4%D0%B0%D0%B9%D0%BB%D1%8B_Pacnew_%D0%B8_Pacsave "Файлы Pacnew и Pacsave"). ### options Этот массив позволяет вам изменить стандартное поведение *makepkg*, указанное в `/etc/makepkg.conf`. Чтобы добавить опцию, включите ее имя в массив. Чтобы инвертировать поведение на обратное, поместите **`!`** в начало опции. Полный список доступных опций можно найти на странице справочного руководства [PKGBUILD(5)](https://www.archlinux.org/pacman/PKGBUILD.5.html). ### install Имя скрипта `.install`, включаемого в пакет. Должно быть таким же, как в `pkgname`. *pacman* может хранить и исполнять специфичные для пакета скрипты во время установки, удаления или обновления пакета. Скрипт содержит следующие функции, запускаемые в разное время: * `pre_install` — скрипт запускается перед распаковкой файлов. Передается один аргумент: новая версия пакета; * `post_install` — скрипт запускается после распаковки файлов. Передается один аргумент: новая версия пакета; * `pre_upgrade` — скрипт запускается перед распаковкой файлов. Передается два аргумента в следующем порядке: новая версия пакета, старая версия пакета; * `post_upgrade` — скрипт запускается после распаковки файлов. Передается два аргумента в следующем порядке: новая версия пакета, старая версия пакета; * `pre_remove` — скрипт запускается перед удалением файлов. Передается один аргумент: старая версия пакета; * `post_remove` — скрипт запускается после удаления файлов. Передается один аргумент: старая версия пакета. Каждая функция запускается в сеансе [chroot](/index.php/Change_root_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Change root (Русский)") в установочном каталоге *pacman*. Смотрите [эту ветку форума](https://bbs.archlinux.org/viewtopic.php?pid=913891). **Совет:** Вы можете использовать шаблон файла `.install` [/usr/share/pacman/proto.install](https://projects.archlinux.org/pacman.git/plain/proto/proto.install) ### changelog Имя файла, содержащего список изменений пакета. Для просмотра списков изменений установленных пакетов (у которых есть этот файл) выполните: ``` pacman -Qc *имя_пакета* ``` **Совет:** Шаблон файла списка изменений: `/usr/share/pacman/ChangeLog.proto` ## Исходные коды ### source **Примечание:** Вы можете использовать специфичные для разных архитектур массивы путем добавления символа подчеркивания и имени архитектуры, например, `source_x86_64=()`. Также должен присутствовать соответствующий массив с контрольными суммами, например, `sha256sums_x86_64=()` Массив имен файлов, необходимых для сборки пакета. Он должен содержать месторасположение исходных файлов программы, которым в большинстве случаев является полный HTTP или FTP-адрес. Здесь вы можете использовать уже установленные ранее значения переменных `pkgname` и `pkgver` (например, `source=("https://example.com/$pkgname-$pkgver.tar.gz")`). Если вам необходимо предоставить файлы, которые не могут быть загружены (например, различные патчи), вы также можете указать их в массиве `source`. Все пути, добавленные здесь, считаются относительными к каталогу, в котором находится `PKGBUILD`. Перед запуском процесса сборки все файлы, прописанные в этом массиве, будут скачаны или проверены на существование, и *makepkg* не будет продолжать свою работу, если какой-либо из них не удалось найти. **Примечание:** Файлы *.install* в этот массив включаться не должны **Совет:** Вы можете присвоить какое-нибудь другое имя загруженному файлу. Для этого используйте следующий синтаксис: `source=('*filename*::*fileuri*')`: `source=("project_name::hg+https://googlefontdirectory.googlecode.com/hg/")` ### noextract Массив имен файлов, указанных в `source`, которые не должны быть распакованы командой *makepkg*. Чаще всего это относится к архивам, которые не могут быть обработаны при помощи `/usr/bin/bsdtar` или должны быть установлены в запакованном виде. Если необходимо использовать альтернативный инструмент распаковки (например, [lrzip](https://www.archlinux.org/packages/?name=lrzip)), он должен быть добавлен в массив `makedepends`, а первая строка функции [prepare()](/index.php/Creating_packages#prepare.28.29 "Creating packages") должна извлекать исходные файлы самостоятельно: ``` prepare() { lrzip -d *source*.tar.lrz } ``` Заметьте, что, хотя массив `source` принимает URL-адреса, в `noextract` следует указывать только имена самих файлов: ``` source=("http://foo.org/bar/foobar.tar.xz") noextract=('foobar.tar.xz') ``` Чтобы вообще не распаковывать *ничего*, вы можете сделать что-нибудь причудливое, вроде того, что здесь (взято из [PKGBUILD'a firefox-i18n](https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/firefox-i18n#n123)): ``` noextract=("${source[@]%%::*}") ``` ## Целостность ### md5sums Массив контрольных сумм MD5 всех файлов, перечисленных в `source`. Как только все файлы из массива `source` становятся доступны, для каждого из них автоматически вычисляется MD5-хэш и сравнивается со значениями это массива в том же порядке, в котором они появляются в массиве `source`. Порядок source-файлов сам по себе не имеет значения, но важно, чтобы он совпадал с порядком в этом массиве, так как `makepkg` не знает, какие контрольные суммы какому файлу принадлежат. Вы можете быстро и легко сгенерировать этот массив, используя команду `updpkgsums` в каталоге, содержащем файл `PKGBUILD`. **Примечание:** Алгоритм MD5 считается слабым, поэтому предпочтительнее использовать более стойкие аналоги из семейства алгоритмов SHA-2 — например, SHA-256. ### sha1sums Массив 160-битных контрольных сумм SHA-1\. Он является альтернативой `md5sums`, описанного выше. Чтобы включить проверку этих контрольных сумм, необходимо включить опцию `INTEGRITY_CHECK` в `/etc/makepkg.conf`. Смотрите [makepkg.conf(5)](http://jlk.fjfi.cvut.cz/arch/manpages/man/makepkg.conf.5). **Примечание:** В алгоритме SHA-1 присутствуют известные слабые места, поэтому предпочтительнее использовать более стойкие аналоги из семейства алгоритмов SHA-2 — например, SHA-256. ### sha256sums, sha384sums, sha512sums Массив контрольных сумм SHA-2 с размерами 256, 384 и 512 бит соответственно. Это альтернативы `md5sums` и `sha1sums`, описанные выше, и они считаются наиболее стойкими. Чтобы включить использование и генерацию этих контрольных сумм, убедитесь, что вы включили опцию `INTEGRITY_CHECK` в `/etc/makepkg.conf`. Смотрите [страницу справочного руководства](/index.php/Man_page_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Man page (Русский)") `man makepkg.conf (5)`. ## Смотрите также * [Страница справочного руководства PKGBUILD(5)](https://www.archlinux.org/pacman/PKGBUILD.5.html) * [Пример PKGBUILD](http://ix.io/66p)